perm filename A29[106,RWF] blob
sn#730321 filedate 1983-10-31 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00003 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 Appendix
C00021 00003
C00035 ENDMK
C⊗;
Appendix
Interpreting Error Messages from the Pascal Compiler
If your program contains syntactic errors, the compiler will provide diagnostic
messages. Some of these are self-explanatory, but others may be obscure.
The examples below show how to interpret the messages resulting from many common
errors.
The following correct program reads the position of a rook on a chessboard, and
prints a picture of the chessboard. The underlined sections are locations where
errors will be inserted to demonstrate error messages.
CORRECT PROGRAM
1 program Rook;
2 var RookRow,
3 RookCol,
4 Row, Col : integer;
5 begin
6 writeln ( tty, ' Rook on Chessboard ' ) ;
7 writeln ( tty, ' ------------------ ' ) ;
8 write ( tty, ' RookRow = ' ) ;
9 break ( tty ) ;
10 read ( tty , RookRow ) ;
11 write ( tty, ' RookColumn = ' ) ;
12 break ( tty ) ;
13 read ( tty , RookCol ) ;
14 while (RookRow < 1) or (RookRow > 8) or (RookCol < 1) or (RookCol > 8) do
15 begin writeln ( tty, ' Invalid input -- Try again ' ) ;
16 write ( tty, ' RookRow = ' ) ;
17 break ( tty ) ;
18 read ( tty , RookRow ) ;
19 write ( tty, ' RookColumn = ' ) ;
20 break ( tty ) ;
21 read ( tty , RookCol ) ;
22 end; (* while *)
23 for Row = 1 to 8 do
24 begin
25 for Col:= 1 to 8 do
26 if Row = RookRow then
27 if Col = RookCol
28 then write ( tty, ' R' )
29 else write ( tty , ' *' )
30 else if Col = RookCol
31 then write ( tty, ' *' )
32 else write ( tty, ' -' ) ;
33 writeln ( tty );
34 end
35 end.
NORMAL OUTPUT
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
Runtime: 0: 0.252
[ROOK execution]
Rook on Chessboard
------------------
RookRow = 4
RookColumn = 6
- - - - - * - -
- - - - - * - -
- - - - - * - -
* * * * * R * *
- - - - - * - -
- - - - - * - -
- - - - - * - -
- - - - - * - -
Line 2: Omit the comma. The resulting error messages follow. The second line
copies a portion of the program where an error was found; the caret is
under the place where the compiler discovered the error, which may be well beyond
where the error occurred. Line 4 refers (``1.∧'') to the first caret, and says
that the symbol ``ROOKCOL'' is illegal there; only a comma or a semicolon would
have been legal in that context. Because of the garbled declaration, the variables
ROOKROW and ROOKCOL are undeclared; nearly every occurrence of those variables
results in an error message. Frequently, many messages will result from one
error, and the first message may be the only useful one.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
3 RookCol,
P* 1** ↑
1.↑: Illegal symbol
13 read ( tty , RookCol ) ;
P* 1** ↑
1.↑: Identifier not declared
14 while (RookRow < 1) or (RookRow > 8) or (RookCol < 1) or (RookCol >
8) do
P* 1** ↑ ↑
1.↑: Identifier not declared
2.↑: Identifier not declared
21 read ( tty , RookCol ) ;
P* 1** ↑
1.↑: Identifier not declared
27 if Col = RookCol
P* 1** ↑
1.↑: Identifier not declared
30 else if Col = RookCol
P* 1** ↑
1.↑: Identifier not declared
? 7 Error(s) detected
Line 11: Omit the closing quote. The resulting error messages follow. The first
message says that the quoted string contains a carriage return. While this
helps locate the errors, it does not accurately describe the error. As a result
of the omittted closing quote, the right parenthesis is treated as part of the
quoted string; as a result, there is a missing right parenthesis, as the second
error message explains.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
11 write ( tty, ' RookColumn = ) ;
P* 1** ↑
1.↑: String constant contains "<CR><LF>"
1.↑: ")" expected
? 2 Error(s) detected
Line 14: Omit all the parentheses. Since Pascal requires parentheses when
relations are connected by AND or OR, the compiler is unable to interpret the
expression.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
14 while RookRow < 1 or RookRow > 8 or RookCol < 1 or RookCol > 8 do
P* 1** ↑** ↑ ** ↑**
1.↑: Illegal symbol
2.↑: Illegal type of operand(s)
3.↑: Illegal symbol
? 3 Error(s) detected
Line 14: Change DO to THEN. The compiler treats this as two separate errors:
the inclusion of an unwanted THEN, and the omission of DO.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
14 while (RookRow < 1) or (RookRow > 8) or (RookCol < 1) or (RookCol >
8) then
P* 1**
↑
1.↑: Illegal symbol
15 begin writeln ( tty, ' Invalid input -- Try again ' ) ;
P* 1** ↑
1.↑: "DO" expected
? 2 Error(s) detected
Line 15: Omission of the semicolon. The omission is detected at the beginning
of the next statement. The compiler ignores a subsequent part of the program,
shown by underlining with asterisks, before starting to translate correctly again.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
16 write ( tty, ' RookRow = ' ) ;
P* 1** ↑**************************
1.↑: Statement must end with ";","END","ELSE"or"UNTIL"
? 1 Error(s) detected
Line 22: Omit the entire line. In addition to the valid error message, a
spurious one is generated. Perhaps the compiler repaired the first error by
inserting only a semicolon; the need for another END is then discovered at
the end of the program.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
34 end.
P* 1** ↑
1.↑: Statement must end with ";","END","ELSE"or"UNTIL"
? Unexpected end of file
Line 22: Omit the second asterisk. As a result, the rest of the program is
treated as a comment, including the ``end.'' which normally terminates a
program. The resulting error message is one of the most cryptic, since it
is located nowhere near the actual error, and does not describe the error.
If all else fails, when the BEGINs and ENDs unexplainably don't seem to match
in a program, check that the comments all terminate properly.
Stanford LOTS/Passgo 20 [ROOK ] -- 1.. ? Unexpected end of file
? Unterminated Comment at 1/22
Line 23: Insert a space between ``:'' and ``=''. Pascal prohibits spaces
within ``:='', ``<>'', ``<='', and ``>=''.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
23 for Row: = 1 to 8 do
P* 1** ↑****
1.↑: ":=" expected
? 1 Error(s) detected
Line 23: Omit the colon. The distinction between ``='' and ``:='' must be
maintained in Pascal.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
23 for Row= 1 to 8 do
P* 1** ↑**
1.↑: ":=" expected
? 1 Error(s) detected
Line 27: Replace ``='' by ``:=''.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
23 for Row = 1 to 8 do
P* 1** ↑**
1.↑: ":=" expected
27 if Col := RookCol
P* 1** ↑*******
1.↑: Illegal symbol
28 then write ( tty, ' R' )
P* 1** ↑
1.↑: Type of operand(s) must be boolean
? 3 Error(s) detected
Line 28: Insert a semicolon at the end of the line. A semicolon before an
ELSE terminates the conditional command prematurely, making an orphan of
the ELSE.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
23 for Row = 1 to 8 do
P* 1** ↑**
1.↑: ":=" expected
29 else write ( tty , ' *' )
P* 1** ↑********************
1.↑: Illegal symbol
30 else if Col = RookCol
P* 1** ****************
? 2 Error(s) detected
Line 35: Omit.
Stanford LOTS/Passgo 20 [ROOK ] -- 1..
23 for Row = 1 to 8 do
P* 1** ↑**
1.↑: ":=" expected
-------
Ordinarily, a careful reading of the error messages will locate a syntactic error.
Occasionally, though, there are few clues. In extreme cases, use the bisection
method. Since this entails radical surgery on the program, you should first
copy it and alter only the copy. Then remove or replace large parts of the
program, such as procedure declarations and compound statements, and see if
the resulting program still gives rise to the same error message. If so,
continue the computations. If not, the error is presumably in one of the
removed parts; put them back in, and remove parts of them, until the error
is localized to a few lines of the program.
Example
PROGRAM - - -
.
.
.
PROCEDURE - - -
.
.
.
PROCEDURE - - -
.
.
.
BEGIN
BEGIN
.
.
.
END
FOR - - - DO
BEGIN
.
.
.
READ(*)
.
.
.
END
END.
This program gives rise to a single error message, ``END OF PROGRAM NOT FOUND''.
This usually results from a non-terminated comment, but the program contains no
comments. First, remove the procedure declarations. The error persists (along
with several new messages about the undeclared procedure names). Next change
the long compound command at the end to a single one, perhaps WRITELN. Now
the error message goes away. The trouble has been located in those lines.
If necessary, restore the compound statement (perhaps by returning to the
previous generation of the file) and delete the component statements one by one.
When the read line is deleted, the error message vanishes. Upon inspection, we see
that READ(*) was typed where READ(x) was intended, the ``(*'' was taken as the
start of a comment, and the rest of the program was taken as part of that
comment.
The bisection method is also a heavy duty method for locating semantic errors
in a program free of syntactic errors. If the results are wrong, make the
program print the values of all variables (called the state) at a point about
halfway through the execution. If they are correct, the problem lies in the
second half of the proram; if wrong, there is something wrong in the first half.
Bisect the offending part again. If the problem has been traced to an iteration,
make it print the state after the first execution, and, if necessary, after the
second, and before the last execution. Usually this will localize the error.
In general, by editing a program, you can make it give you enough information
to locate its errors, assuming that you understand what the program was supposed
to be doing.
LOTS Note
The printers at LOTS can readily be jammed or otherwise incapacitated by careless
users. Because LOTS is a Low Overhead time sharing system, often there is no
one around more qualified than you to fix printer malfunctions. If the printer
jams, or if it is running out of ink:
. If you can, find a LOTS staff member to repair the condition.
. Otherwise, see if you can find a user who knows how to repair it.
. Watch what the fixer does, and read the instructions posted near
the printer.
. Next time, try it yourself. Even professors can do it, it's not hard.
LOTS Note
An important part of learning to program well is reading many good programs.
The directory <C.CS10X> contains an abundance of example programs, most of
them solutions to past assignments in CS105 or 106, or examples which have
been used in class. You can read them, execute them, or modify copies of
them. You may copy useful parts of them into your own programs.
LOTS Note
LOTS has limited storage for files containing student programs, data, and
output. When the storage is full, no more programs can be accepted. Please
help keep your usage of storage to a minimum.
. Delete any files you no longer need---for example, a program for an
assignment you have already turned in. Keep a paper copy, in case
the assignment is lost. LOTS has backup copies on magnetic tape, of
anything that has been in a file more than a week, so old programs can
be recovered if needed.
. Delete as soon as possible any files you can easily reconstruct, such
as Pascal output files.
. Don't make exact copies of other files, except for immediate modification.
Instead, use the original itself.
. Use @HELP CLEAN for information about an easy way to clean out
your directory.